QRZ! Ham Radio 4/QRZ Ham Radio Callsign Database - Volume 4.iso/digests/digital/940123.txt

Internet Message Format | 1994-11-13 | 23KB

Date: Wed, 20 Apr 94 04:30:13 PDT
From: Ham-Digital Mailing List and Newsgroup <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: Ham-Digital Digest V94 #123
To: Ham-Digital


Ham-Digital Digest          Wed, 20 Apr 94       Volume 94 : Issue  123

Today's Topics:
               **BYTE Magazine** features DSP, May 1994
                     Internet <-> packet gateway?
                     Internet > Packet gateways??

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Ham-Digital Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Tue, 19 Apr 1994 14:38:24 GMT
From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!vixen.cso.uiuc.edu!uchinews!kimbark![e-mail]
Subject: **BYTE Magazine** features DSP, May 1994
To: [e-mail]

F.Y.I.
-----
There are two excellent articles about DSP in the  new  May  1994
issue of BYTE Magazine.

The first on pp22,23 carries the title "The Engines to Make  Mul-
timedia Mainstream".  This two pager covers the Microsoft DSP API
and a nice half-page on the TI TMS 32OC80.  The article has a pie
chart  that indicates a trememdous growth (728$mill to 2,493$Mil)
in DSP sales from 1993 to 1997.

The second article is on pp 81-86 and has the title "Desktop Data
Conferencing".   There is an excellent chart showing various pic-
ture formats and the corresponding  required  bandwidth  for  un-
compressed and compressed transmission. DSP is highlighted as the
solution to bringing Teleconferencing to our  bandwidith  limited
telecommunication  channels. Page 84 has a 2/3 page special inset
on "DSP's and the PC Mainstream" that clarifies the DSP  API  and
the  AT&T  VCOS, IBM MWAVE, and SPOX.  The various "DSP Operating
Systems" are displayed in a brief figure on the same page.   Page
86    has    a    table   depicting   15   different   alforithms
(CLEP...G.711...V.32...) and their bit stream speeds and DSP  re-
quirements.

Good articles with more than introductory information.

                                ___________
  Ken Hopper,                  |    ___    |
  November 9 Vivid Video       |o o \_/ o o|
  HF - CW,PacTOR,RTTY,SSTV     |o o  @  o o|
  [e-mail]  |___________|

------------------------------

Date: Tue, 19 Apr 1994 15:39:13 GMT
From: ihnp4.ucsd.edu!pacbell.com!tandem![e-mail]
Subject: Internet <-> packet gateway?
To: [e-mail]

In article [e-mail], [e-mail] (Robert Ansaldo) writes:
>I seem to remember seeing something here about an internet connected machine
>that will forward email via packet radio. I tried looking back, but the
>article(s) must have expired.


N6QMY/BBS Internet Gateway Operating Instructions
April 11, 1993

LOCAL USERS:
------------
Local users are those that log into the bbs via the bbs's telephone modem
port (510-795-xxxx) or via one of the 4 tnc ports (145.09, 145.79, 223.62,
or 441.50).  Each local user has a bbs account that is used to customize
how the bbs interacts with the user.

Local users can set their account up so that all incoming mail addressed
to their call will be forwarded via a gateway to internet and on to
other networks (mcimail, compuserve, etc). All the user needs to do is
enter his email address and turn the feature on.

  EMAIL [e-mail]
  EMAIL ON

When the EMAIL feature is turned on the packet message will be deleted
at the time of forwarding through the gateway. So care should be taken
that the paths are correct prior to turning the feature on, for instance
enable it, send a test message, and disable it. After a successful
transfer re-enable the feature. To disable the auto forwarding feature
simply type:

  EMAIL OFF

Messages can be sent by packet users to the internet users via the gateway.
This applies to users at N6QMY as well as users at other bbs's. Begin by
sending a message to IPGATE@N6QMY with the first line of the message being
the letters "To:" followed by the internet address of the recipient.

  KB6UCZ de N6QMY >
    sp ipgate@n6qmy
  Enter your subject:
    Meeting?
  Enter your message body:
    To: [e-mail]
    Are you planning to attend the club meeting on Thursday? Give me
    a call. 73, Theresa
    ^Z

NOTE: That the recipient cannot respond to the message unless they
are a ham and registered with the gateway. He/she becomes registered by
sending a message from his internet host to [e-mail].


REMOTE USERS:
-------------
Remote users are those that do not log into N6QMY directly but merely
appear from the packet world to use it as home. If a packet user checks
the "White Pages" for a remote user the entry comes back as @N6QMY.
The packet user then address his message to YOURCALL@N6QMY and the
bbs will do the translation and forwarding to internet.

It is not necessary for a person to know your actual internet address
nor use the SP IPGATE method described above. From the packet network
it appears that you are just another user at N6QMY.

WHITE PAGES:
------------
The "White Pages" is a distributed database of all the bbs users. Most
bbs users in the US are represented in the database as well as many from
other countries. When a user chooses a home bbs, that bbs generates
an update that is sent to the regional servers and then distributed to
all the other bbs's. An entry consists of; call, home bbs, first name,
zip, city and state. When a user wishes to send another packet user
a message he/she consults the white pages (WP) for the home bbs.


REGISTERING:
------------
Before a user, both local and remote, can send a message from internet
into the bbs system he/she must register with the gateway. This is done
by sending a message from the host that he/she intends to use to
[e-mail] with the following information:

  CALL:
  FIRST NAME:
  CITY & ST:
  ZIP:

  HOME BBS:

When a request is received the "From" field is copied directly into
a file with the requesters call. Whenever the gateway receives a message
bound for packet it scans this file comparing on the "From" field. When a
match is found the gateway uses the associated call from then on. If
there is no match the mailer bounces the message with a one-liner
indicating the the user must register.

If you currently use another bbs as home this needs to be stated
in the request. Otherwise you will be assigned N6QMY as your home.
If you choose not to use N6QMY as your home you must make sure
people know to send your message to YOURCALL@N6QMY to pass through
the gate. Your WP entry will be wrong.


EXECUTING BBS COMMANDS REMOTELY:
--------------------------------
Many of the commands available to local users is also available to
remote users by sending a message to the bbs. Here is a subset of
the commands currently available.

  LIST          listing messages
  LOOKUP        look up calls in the on-line callbook
  WHO call      dump a users account information
  READ          read messages and files
  USERS n       display the last n users to connect to the bbs
  INFO          display manual pages of various topics
  CD            change directories in the file system
  LS/DIR        display the contents of a directory
  WP call       look a user up in the "White Pages"
  HELP          get help on how to use a command

Not all commands available to local users can be accessed via the
gate. All interactive commands are disabled as well as commands
that modify the users account.

The command parser for the bbs is very powerful and the user can
form very complex requests. For instance the following command
is valid on the bbs:

  LIST LAST 20 BULLETINS FROM N6QMY
  LIST ALL BULLETINS ABOUT KENWOOD

The ABOUT keyword is used to search the subjects of messages for a
given pattern, in this case KENWOOD. It can appear anywhere in the
subject line.

This is an example of how complex all the commands can become. They
can also be abbreviated down to the level understood my most other
bbs programs. Any of the following will give the same results.

  L< N6ZFJ
  LIST FROM N6ZFJ
  LIS < N6ZFJ
  L FR N6ZFJ

In most cases a minimum number of unique characters is needed to
distinguish a command.

You can get a list of commands and a translation chart from the
W0RLI BBS command set to the N0ARY BBS command  set by typing
the following commands:

  INFO COMMANDS
  INFO W0RLI

Other commands that you may wish to execute are:

  INFO MANUAL
  HELP HELP
  HELP LIST

Now that you know what some of the commands are this is how you go
about executing them. You send a message to [e-mail]
with your commands entered one per line or separated by semicolons.
For example if you want to know if three of your buddies are in
the white pages and if the bbs has any messages about the ICOM W2A.

Send to:
  [e-mail]

  Subject: you can put anything here
  wp n0ary n6zfj n6une
  list all about w2a
  .

The bbs will execute the commands and respond to you via return mail.

SENDING MAIL TO PACKET:
-----------------------
Once registered the user is free to begin using the gateway to send
messages from his host through the gateway into the packet world.
How much you have to specify of a users address depends on how much
the bbs already knows about the user.

If the bbs knows the home bbs of the user and his home bbs is know to
the N6QMY bbs, which many of them are, you simply need to supply
the call of the user.

  [e-mail]

If the N6QMY bbs doesn't know of the user but does know where his
home bbs is, then you need to supply just the home bbs call in
addition to the users.

  [e-mail]

Notice that the call and home bbs are separated by a percent sign '%'
rather then the '@' which is used in the packet domain. This is because
the '@' has a meaning in the internet address.

If the N6QMY bbs has no knowledge of either the user or his home bbs,
then you probably have the wrong home bbs or it is a new bbs. In which
case you will have to supply the full address so the bbs will know
how to route the message.

  n6oim%n6iiu.#[e-mail]

This level of addressing is hardly ever needed and normally means that
the home bbs is in error.

Bulletins can be sent in a similar fashion. The address is made up
of a keyword, which can be any six character word and a distribution.
Distributions are local to an area. For instance SBAY is valid in
northern CA, it probably has no meaning at all in Topeka, KS.

Valid distributions are:
    ALLUS           please avoid this one
    ALLUSW            all western US
    ALLCA            all California, any 2 letter state should work

So if you trying to find a cw filter for a Kenwood TS440.

Send to:
  [e-mail]

  Subject: Kenwood TS440, CW filter
  If you have one of these you are willing to part with please
  give me a call or leave message, thanks.
  73, KB6UCZ@N6QMY.#NOCAL.CA.USA.NA
  .

Be descriptive, brief, and always include your full return address in
the message. Also please try to limit your distributions to small
regions. Using the ALLUS distribution really slows down the flow of
messages.

INFO ON THE N6QMY BBS:
----------------------
The bbs came into being in April of 1993 and was the second one anywhere
to run the N0ARY BBS code (the first being N0ARY himself).  The bbs has
4 rf ports, 1 phone port, the internet port, and is working on a voice synthesizer port. The latter would allow users to check for messages
via DTMF from their handhelds.

The bbs itself runs on a Sun workstation under Unix. The code was
written by Bob Arasmith (N0ARY) to focus on the user. Great care was
taken to make the bbs very forgiving to the novice user but very flexible
and powerful for the old-timer. The bbs can be configured to interact
with each user differently. Some examples are:

 * List messages in either descending or ascending order.

 * Specify a list of keywords that the user wishes not to see displayed
   when a list is performed, similar to a kill file.

 * .signature and .vacation files.

 * Specify how many lines the users terminal is capable of displaying
   before scrolling, the bbs will feed info this many lines and pause
   allowing the user to catch up and continue or abort the operation.
   Similar to more.

 * Users can put commonly executed commands in keystroke macros that
   are accessible via a single keystroke.

A manual is currently available describing the commands and their
permutations. This manual will be available later this year as a
postscript file. Run the command INFO MANUAL to learn how to get
one via the post office. It is not available in an ascii format.

If you have any questions about the internet gateway or the bbs
in general please drop me a message.

73,   -pat
         n6qmy@n6qmy.#nocal.ca.usa.na
         [e-mail]

------------------------------

Date: 19 Apr 94 20:10:06 GMT
From: agate!howland.reston.ans.net!europa.eng.gtefsd.com!library.ucla.edu!ihnp4.ucsd.edu!pacbell.com!amdahl!amd!netcomsv!telesoft![e-mail]
Subject: Internet > Packet gateways??
To: [e-mail]

In <[e-mail]> [e-mail] (Marc B. Grant) writes:
>Does anyone have a list of Internet > Packet gateways?  I use N0ARY, but
>would like to find others closer to some other geographic locations.

Here is the short list of I have.  It's probably not complete and some of
the older ones may no longer be operating.  I haven't verified any of these
except N0ARY which the one I use.

Does anyone know of any we can add to the list?  Especially any in
Southern California?
--GaryM


      Internet Email / Amateur Packet Gateways

Location        BBS     Contact Address                 Date of Info
--------------  ------- -----------------------         ------------
Sunnyvale, CA   N0ARY   [e-mail]       94-04
Fremont, CA     N6QMY   [e-mail]            94-02
Arizona         WB7TPY  [e-mail]                  93-05
New Jersey      KA2QHD  [e-mail]      92-05
Pittsburg       W2XO    [e-mail]           92-05

------------------------------

Date: Tue, 19 Apr 1994 15:51:02 GMT
From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!news.intercon.com!panix!zip.eecs.umich.edu!yeshua.marcam.com!news.kei.com!eff!blanket.mitre.org!world![e-mail]
To: [e-mail]

References <2oh1qh$[e-mail]>, <2okn8t$[e-mail]>, <2om9kt$[e-mail]>ich.edu
Subject : Re: NTS traffic on packet

In article <2om9kt$[e-mail]> [e-mail] writes:
>In article <2okn8t$[e-mail]>, [e-mail] (Hank Oredson) writes:
>>In article <2oh1qh$[e-mail]>, [e-mail] (Mike Stansberry) writes:
>>|> Hank Oredson ([e-mail]) wrote:
>>|> : In article <2oblv6$[e-mail]>, [e-mail] (Mike Stansberry) writes:
>>|> : |> Hank Oredson ([e-mail]) wrote:
>>|> : |> : In article <[e-mail]>, [e-mail] (Dan Ostroy ) writes:
>>|> : |>
>>|> : |> : The days of handling traffic on 80M CW are pretty much gone now, just
>>|> : |>                                   ^^^^^^
>>|> : |> **** WRONG!!! ***  Just because YOU don't do it, don't assume it's
>>|> : |> gone.  I handle a LOT of traffic on 80M (and 40M) CW and so do a
>>|> : |> lot of others!
>>|> : |>
>>|> : |> Mike, K0TER
>>|> : |>
>>|>
>>|> : I'm certainly sorry to hear that.
>>|>
>>|> : Sounds terribly inefficient and error prone, when there are
>>|> : better ways to do it.
>>|>
>>|> : --
>>|>
>>|> : Hank Oredson @ Mentor Graphics
>>|> : Internet     : [e-mail]
>>|> : Amateur Radio: [e-mail]
>>|>
>>|> I guess you are just not interested in trying to help.  Use your
>>|> system or none at all, right?  End of discussion.
>>
>>*** Flame mode on:
>>
>>So what should I do to try and help?  Spell it out and stop whining.
>>
>>I guess differently than you do: I am trying to help by working to create
>>a network that will gaurantee error free movement of messages
>>anyplace in the world.
>>
>>Did I say "none at all"? No I did not.
>>Please pay attention and read what was written (it's right up there ..).
>>I said that 80M CW sounds terribly inefficient and error prone.
>>
>>Your response is what I hear from the majority of hams presently involved
>>in NTS: "Oh my, Oh my, Run Away! - the Computers are coming, and we are
>>afraid they will replace us!"
>>
>>In what way would you like me to help? By getting on 80M CW?
>>No thanks, I've done that, and know perfectly well that it is error
>>prone, slow, and can handle only a tiny amount of traffic.
>>
>>What I have been saying is that NTS fails to make use of all
>>resources available to it, and in particular appears to be stuck in
>>the dark ages of message handling.
>>
>>"End of discussion" sounds a lot like "I refuse to hear what you have
>>to say, and will continue to refuse to hear it."
>>
>>*** Flame mode off:
>>
>>
>>Indeed, not all NTS participants are like Mike.
>>
>>Some appear to understand what *could* be done, and would like to move
>>NTS forward.  However from my experience they are in the minority, and
>>the "Mikes of the world" are in the majority.
>>
>>   ...  Hank
>>
>>--
>>
>>Speaking only for myself (but you knew that, didn't you)
>>
>>Hank Oredson @ Mentor Graphics
>>Internet     : [e-mail]
>>Amateur Radio: [e-mail]
>If CW/VOICE is so efficient, why does NTS highly suggest that msgs be limited
>to 20 or 25 words or less. Compare that to length of many msgs/bulls on pkt.
>bill Hays, W0OMV

I guess you don't deliver much traffic. Some of us who do, prefer not to
spend our whole lives at it. Remeber that there IS a human doing the delivery
at the other end, and that NTS traffic is often send by and received by
NON-hams.


--
---------------------------------------------------------------
Daniel Senie                 Internet:     [e-mail]
Daniel Senie Consulting                    [e-mail]
508-779-0439                 Compuserve:   74176,1347

------------------------------

Date: Tue, 19 Apr 1994 15:57:38 GMT
From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!news.intercon.com!panix!zip.eecs.umich.edu!yeshua.marcam.com!news.kei.com!eff!blanket.mitre.org!world![e-mail]
To: [e-mail]

References <2okn8t$[e-mail]>, <2om1ki$[e-mail]>, <2oujlo$[e-mail]>um
Subject : Re: NTS traffic on packet

In article <2oujlo$[e-mail]> [e-mail] writes:
>In article <2om1ki$[e-mail]>, [e-mail] (Mike Stansberry) writes:
>
>|> Tell me what needs to be done to stop doubling, tripling, or even more
>|> of messages.  Tell me what needs to be done to get the time in transit
>|> of messages sent via packet down from 5 to 10 days to something
>|> reasonable.  Don't tell me the above statements are not true.  I'm
>|> keeping track of the header information on the messages I deliver
>|> that travelled by packet and the 5 to 10 days is the norm/.
>
>Ok, I'll tell you what to do to solve these problems.
>
>This is what we do in our part of the network whenever problems such
>as you describe occur.  Once located, the problem is usually quickly fixed.
>
>With respect to these 5-10 day delays you claim to see:
>
>1.  Track the messages to find out where the delays occur.
>2.  Send this information to SYSOP@USA (or to the appropriate sysops
>    directly) so everyone involved knows where the problems occur,
>    and can work to fix them.
>3.  Create better routings so the delays do not occur.

These are all excellent suggestions. The problem is, the folks who handle
NTS traffic are not necessarily interested in the WAY that the tool (packet)
works, just that it does work. I don't see anything wrong with that approach
to packet at all. I, for one, do network stuff for a living, and like to do
something OTHER than debugging networks when I get home.

Perhaps the packet network systems should have some sort of routine test
messages that get spread over the various paths and analyzed? There is no
real reason to rely on end users to report problems of this sort.

>
>If the above is not clear, then simply post a few messages to SYSOP @ USA
>including the headers from these delayed messages.  We can't fix anything
>until we know where the problem occurs.  You have not given us that
>information yet.
>
>With respect to the duplicates you claim to see:
>
>1.  Track the messages to find out where the duplicates occur.
>2.  Send this information to SYSOP@USA (or to the appropriate sysops
>    directly) so everyone involved knows where the problems occur,
>    and can work to fix them.
>3.  Adjust your forwarding or connect parameters so the duplicates
>    no longer occur.
>
>If the above is not clear, then simply post a few messages to SYSOP @ USA
>including the headers from these duplicated messages.  We can't fix anything
>until we know where the problem occurs.  You have not given us that
>information.
>
>The above is simply common sense: it is how we manage the network so it
>will meet reasonable requirements on delay times, etc.
>
>Do we see delays and duplicates like this in the Pacific NW?
>Yes, of course we do.
>Do we allow them to continue?
>No, we do not.
>We manage the network to locate and repair problems like this.
>They are usually simple problems that yield to simple solutions.

Now if the network were as well managed everywhere, we'd be all set. It
takes people who WANT to spend their ham radio time doing this. I'm sure there
are such people all over, but they are not necessarily the ones handling NTS
traffic.

>
>   ...  Hank
>
>--
>
>Hank Oredson @ Mentor Graphics
>Internet     : [e-mail]
>Amateur Radio: [e-mail]


--
---------------------------------------------------------------
Daniel Senie                 Internet:     [e-mail]
Daniel Senie Consulting                    [e-mail]
508-779-0439                 Compuserve:   74176,1347

------------------------------

End of Ham-Digital Digest V94 #123
******************************